Add solana-pay-request: build a Solana Pay transfer-request URL, no permissions - #156

Adds solana-pay-request, a tool plugin that turns a payment intent into a Solana Pay transfer-request URL and a QR-ready payload a customer's wallet scans to pay.

Given a recipient and an optional amount, SPL mint, reference keys, label, message and memo, it validates every field and builds a solana: URL faithful to the Solana Pay spec. The agent-facing shape is one tool call: "charge table 4 for 25 USDC" comes back as a scannable URL.

solana:mvines9iiHiQTysrwkJjGf2gb9Ex9jXJX8ns3qwf2kN?amount=25&spl-token=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v&memo=table%204

Custody: permissions = []

It holds no key, reads no config and opens no socket. That is not a claim about the source, it is a property of the component: a WASI interface can only be imported by name, so the name is in the binary if the capability is reachable. On this build:

wasi:http 0        wasi:cli 23
wasi:sockets 0     wasi:io 11
wasi:filesystem 0  zeroclaw:plugin 15

The right-hand column is the control. Three zeros mean nothing unless the same command returns non-zero for interfaces that are genuinely present, and the README ships both loops so a reviewer can re-run them against the artifact they built rather than take the numbers from me.

Nothing it emits can move money on its own. The output is a payment request; the payer's wallet builds and signs the transaction.

Free text cannot restructure the URL

recipient, amount, spl-token and reference each arrive in their own typed field and are validated before the URL is built. label, message and memo are stripped of control, bidi and zero-width characters, then percent-encoded at build time. A memo reading table 4&recipient=<attacker>&amount=999 becomes one encoded memo value rather than a second recipient, which is pinned as an integration test.

Vendoring

src/solana_core/ is copied from the plugin's source repository, with the repository, revision and file paths named in its module header.

Vendoring is deliberate rather than convenient. A plugin here is built from its own directory plus wit/, so a path dependency reaching outside that directory cannot resolve, and the crate it would name is unpublished. sanitize.rs is verbatim. pubkey.rs is cut down to the base58 codec, which drops the curve25519-dalek, ed25519-dalek and sha2 dependencies that only the omitted PDA and on-curve code needed; the reduction is recorded in the file so a future need for derivation pulls the upstream module back whole instead of regrowing it by hand. bs58 is the one dependency added beyond the template's.

What I ran

Against this branch, from plugins/solana-pay-request/:

tools/ci/validate_components.sh solana-pay-request was also run directly, so the four cargo commands above were exercised through the snapshot the workflow actually builds in rather than in a working tree that happened to have more in it.

Two caveats, stated rather than left for CI to surface. The tools/tests and tools/ci/tests suites report failures on my machine, but they fail identically on an unmodified checkout of main and every failing case is a symlink or non-regular-file test, which is a Windows limitation rather than anything this branch touches. And registry.json is untouched, since it is generated.

Fit

The registry currently indexes one tool plugin against thirty channel plugins. This is a tool plugin with no permissions at all, which makes it about the cheapest possible thing to review and install, and it is useful to any agent on any of those channels: taking a payment is not chain-specific plumbing, it is the thing the operator wanted the agent for.

Happy to split the vendored module out, rename, or adjust the manifest if any of it cuts against how you would rather see third-party plugins land here.

Validation

CI does not run on pull requests from forks in this repo, so here is the output of your own
validator, unmodified, on this branch:

test_rc=0  tests_passed=84  clippy_rc=0  wasm_clippy_rc=0
build_rc=0  artifact_bytes=202662  strict=true  registry=true

Reproduce with:

bash tools/ci/validate_components.sh --plugin solana-pay-request --strict --registry

Also clean: cargo fmt --check, git diff --check against main, and --check-metadata, which
reports pending unpublished source: solana-pay-request@0.1.0.

The manifest declares permissions = []. That is verified against the built artifact rather than
the source: wasi:http, wasi:sockets and wasi:filesystem each appear 0 times in the component,
with wasi:cli at 23, wasi:io at 11 and zeroclaw:plugin at 15 confirming the check reads the
binary.

Two limits worth stating rather than leaving you to find. It was built on Rust 1.97.1, not the
1.96.1 your workflow pins, so that combination is untested by me. And it has not been built on
Linux; your tools/tests and tools/ci/tests suites fail on my machine, but they fail
byte-identically on an unmodified checkout of main and every failing case is a symlink test, so
that looks pre-existing and platform-specific rather than related to this change.